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REMARKS 

Claims 1 to 4 and 6 to 20 are pending in the application. Applicants respectfully 
traverse the rejections for at least the following reasons. 

Interview Summary: 

An interview was held in this case on August 5, 2009. Applicants thank the Examiner 
for the courtesy of an interview. During the interview Applicants' representative presented 
the perceived fundamental differences between the present invention and the prior art. 
Specifically, how a revenue budget differs from a revenue posting database and from an 
expenditure budget. The Examiner discussed the basis for disagreeing. No agreement was 
reached on possible amendments to overcome the presently asserted prior art. 

Claim Rejection Under 35 U.S.C. § 102(b): 

Claims 1 to 20 were rejected under 35 U.S.C. § 102(b) based upon alleged public use 
or sale of the invention with reference to the "2000 Development Requests at HERTUG 
(Higher Education and Research Institutions)" [sic] as seen at http://web.mit.edu/her/devreq/ 
votedevreq00.htm ("HERUG reference") at item 7. Applicant respectfully requests 
withdrawal of the outstanding rejection because the HERUG reference does not teach or 
suggest all elements of the pending claims. 

Before discussing the limitations of the HERUG reference, Applicant respectfully 
requests the Examiner to reconsider the background of the application to develop an 
appropriate context for the claimed subject matter. The present application acknowledges 
that RIB processing has been performed in prior Enterprise Management Applications but 
identified several deficiencies with the prior attempts. For example, the specification states: 

[An] organization may be permitted to spend additional monies pursuant to an 
identified program if its revenues exceed a predetermined threshold amount. 
Such budgetary dependencies are called "revenues increasing the budget" (or 
simply, "RIB") and vary widely in their implementation. When a new revenue 
item is posted within the system, the EMA system may apply one or more RIB 
rules to determine whether the revenue item causes an increase in some 
expenditure budget item. The EMA system may amend values in the 
expenditure budget database to reflect any RIB increase that the new revenue 
item may cause. 

Many organizations, particularly public sector organizations, require that the 
revenue budget and the expenditure budget remain balanced. Through the 
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course of the fiscal period, as the organization posts revenue and RIB 
increases are made to the expenditure database, values of the expenditure 
budget database no longer balance with the revenue budget database. When 
audit functions are performed, this artifact causes difficulty to determine 
whether the organization's goals are being met. Accordingly, there is a need in 
the art for a budgetary control system that demonstrates balance between 
revenue and expenditure budget structures even when the expenditure budget 
increases according to RIB rules. 

Thus, the background acknowledges that known EMA systems processed RIB rules but those 

prior solutions recorded data in ways that cause expenditure databases to become unbalanced 

with respect to the revenue databases. Against this background, the present invention 

proposes a solution. 

Claim 1 defines a solution that retains balance between expenditure databases and 
revenue databases in ways that were not accomplished by the EMA systems discussion in the 
Application's Background. Claim 1, for example, states: 

executing a RIB rule to determine whether the new transaction causes an 
increase to an expenditure budget; 

if the new transaction causes an increase to the expenditure budget, storing the 
budget increase in a node of an expenditure budget data structure with an 
indication that the node represents an increase in the expenditure budget; and 
storin2 the budget increase in an identified node of a revenue budget data 
structure with an indication that the node represents an increase in the 
revenue budget, wherein values in the expenditure budget data structure 
balance with values in the revenue budget data structure. 

Turning to the HERUG reference, note 7, Applicants can find no discussion anywhere in that 

reference to suggest that the suggestions logged therein meet the substance of the pending 

claims or that the problems identified in the Application's Background would be solved if the 

suggestions made in note 7 were adopted. 

Note 7 of the HERTUG reference states in relevant part: 



TITLE DESCRIPTION BUSINESS MOTIVATION SAP COMMENT 



Improve Improve RIB functionality Currently we use RIB, it is critical to It would make sense to 

Revenues [Transactions FMFO, F- 02, our Research area and it is unify the systems 

Increasing FMIC and FMIB] activated at sales invoice. The reaction to processes 

Budget 1. When RIB is set to increase University has made a decision to which do not finally lead 

budget on payment of invoice, change the critical event to increase to payments. The full 

only documents of value types budget on payment of invoice. This scope of RIB 

57 and 66 activate RIB, we wil1 improve our cashflow and to. functionality also is 

require that this is extended to However the functionality is lacking. reconsidered with the 

other value type 54 1. Revenue from donations via the development of the new 

transactions which will never payroll (document type SL; type 30) budget execution tool, 

be technically paid and stay at should increase budget. Similarly 

value type 54. exchange rate differences and 
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settlement discounts posted via 
batch journals should also increase 
budget (value type 54). 

2. Budget is sometimes given in a 
previous fiscal year, we then have to 
manually journalise this into the 
current fiscal year. 

3. Revenues are posted to many 
account Assignment Revenue 
Commitment Items in the Fund 
Centre / Fund combinations. As 
upper limits can only be set for 
Account Assignment Commitment 
Items of Financial Transaction 30 
and Item Category 2 the current 
Revenues Increasing Budget "upper 
limit" functionality does not fit UCT's 
business requirement 



Note 7 makes no reference to balancing budgets between expenditure databases or revenue 
databases. Indeed, a word search of the entire HE RUG reference indicates that the term 
"balance" is used nowhere in the entire document. Applicants have reviewed the discussion 
of note 7 and can find no discussion anywhere that corresponds to the elements of claim 1, 
other than the fact that it uses the same buzzword - RIB. As explained above, Applicants 
acknowledge that RIB processes pre-date the present application; Applicants have developed 
a solution that solves a specific problem that is presented by prior attempts to support RIB 
processing. Applicants, therefore, respectfully request that the Office withdraw the 
anticipation rejection based on the HERUG reference. 



2. When RIB is set to increase 
budget on payment of invoice, 
the budget is increased in the 
year the invoice was posted 
and not the year of payment; 
we require that budget is 
increased in the year of 
payment. 

3. RIB thresholds, Restrict 
budget increases by revenues 
to an overall amount. 



Claim Rejections Under 35 U.S.C. § 103(a): 

Claims 1, 4, 6, 14, 17, 19, and 20 stand rejected as obvious over a PowerPoint® slide 
presentation regarding, Introduction to Management Accounting 12/e, 

Horngren/Sundem/Stratton, 2002, Prentice Hall Business Publishing ("Prentice"), in view of 
U.S. Patent No. 6,275,813 ("Berka"), and in further view ofU.S. Patent No. 7,131,579 
("Kim"). Claims 2, 3, 7 to 13, 15, 16, and 18 stand rejected as obvious over Prentice, Berka, 
Kim, and U.S. Patent No. 6,073,108 ("Peterson"). 

Claims 1, 4, 6, 14, and 17: 

Claims 1, 4, 6, 14, and 17 were rejected under 35 U.S.C. §103(a) as being 
unpatentable over a PowerPoint® slide presentation regarding, Introduction to Management 
Accounting 12/e, Horngren/Sundem/Stratton, 2002, Prentice Hall Business Publishing 
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("Prentice"), in view of U.S. Patent No. 6,275,813 ("Berka"), and in further view of U.S. 
Patent No. 7,131,579 ("Kim"). 

Prentice is again cited for the general and known accounting principles regarding 
flexible budgets. Berka is cited against the specific features of the present claims, in view of 
Kim, which is cited only for a journaling of financial transactions. Specifically, Berka is 
cited as disclosing, "a computerized system of double-entry financial accounting and, in 
particular, to a method of entering data from financial transactions . . . according to known 
accounting theory of debit and credit." Berka at 1 :1 1-26. However, the "known accounting 
theory of debit and credit" is not applicable to the features of claim 1. As Berka explains, 
"any financial transaction can be defined by a single posting record that includes, apart from 
its reference number, date, currency and monetary amount, a category directional code 
consisting of a destination category and a source category." Berka at 1 :50-54. 

To this, the Office now states that "one of ordinary skill in the accounting arts knows 
that any revenue recognized by an organization must be balanced in some manner when 
posted. RIB as defined by the applicant is revenue which results in the increase in the budget 
of an organization, the amount that a budget is increased may be organization specific; 
however as with all accounting entries they must be balanced." The Office appears to be 
asserting the Berka reference against some abstract characterization of what the SAP 
budgeting system, as a whole, may or must include. Applicants respectfully request that the 
specific features of the present claims be addressed. Claim 1 recites storing the revenue in 
both the revenue budget and expenditure budget, which is inapposite to adding to one entity 
and subtracting from another entity, as required by credit/debit procedures, and is further 
inapposite to a single database entry, as disclosed in Berka. Berka may disclose some 
accounting methods, but does not disclose the specific features of : "if the new transaction 
causes an increase to the expenditure budget, storing the budget increase in a node of an 
expenditure budget data structure . . . and storing the budget increase in an identified node of 
a revenue budget data structure ..." 

None of the cited art discloses "a revenue budget database." Prior art may include a 
revenue posting database, e.g., a database to record actual revenues in their incoming form. 
However, this is very different from "a revenue budget database." As explained in the 
present specification, "Revenue budgets typically forecast revenues that the organization 
expects to earn over a predetermined fiscal period" Specification at paragraph 3 (emphasis 



9 



Applicant: Andres SCHAEFER, et al. 
Serial No. 10/73 0,948 

Response to the Office Action of May 19, 2009 



11884/407001 



added). A revenue budget, as distinct from a revenue posting database, is not found in any of 
the prior art reverences - including the HERUG reference. It is believed to be rejected as 
obvious based on the Office's conclusion that "one of ordinary skill in the accounting arts 
knows that any revenue recognized by an organization must be balanced in some manner 
when posted." This may be true, but it has nothing to do with increasing a revenue forecast, 
i.e. a revenue budget. The revenue budget is a prediction/expectation, and unrelated to the set 
of known financial transactions. There is simply no basis to characterize "storing the budget 
increase in an identified node of a revenue budget" as inherent to the RIB operation of 
increasing an expenditure budget. 

For at least this reason, as well as those previously argued, Applicants respectfully 
request the rejection be withdrawn. 

Claim 4: 

Claim 4 is allowable, at least because Berka, and known credit/debit accounting, are 
inapplicable to the feature of "storing expenditure budget items in a database, so that the 
revenue budget items balance with the expenditure budget items." The credit/debit 
accounting of Berka "records actual transactions as transfers of money between two" 
accounts. Berka at Abstract. A revenue budget is not an account, an expense budget is not 
an account, and a RIB rule does not transfer money between accounts. 

To this, the Office "must disagree [, and states that it] is clear from Applicant's 
specification that the invention is about a financial management system for revenues and 
expenditures . . . [and] one of ordinary skill in the accounting arts knows that in any 
accounting system, money is not necessarily transferred between accounts during the 
debit/credit process; it is a financial recording of a transaction or transactions of an 
organization." Even if true, Berka does not disclose it. If the Office is taking Official Notice 
of something believed to be well known in the art, Applicant respectfully requests said Notice 
be given in proper form, so that Applicants may provide a substantive response. The Office 
admits that this is not inherent to the Berka disclosure (see underlined phrase above), and 
thus, it must be that some unnamed reference or personal knowledge is being combined with 
Berka to disclose the presently claimed features. The transfer of money from different 
accounts does not identically disclose or suggest the claim feature of revenue/budget data 
structures. For at least these reasons, Applicants respectfully request the rejection of claim 4 
be withdrawn. 
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Claim 6 and 14: 

Claim 6 is allowable, at least because Berka, and known credit/debit accounting, are 
inapplicable to the features of "an expenditure budget database to store the budget item, and a 
revenue budget database to store the budget item, wherein the RIB rule processing system is 
configured to maintain a balance between the expenditure budget database and the revenue 
budget database." The credit/debit accounting of Berka "records actual transactions as 
transfers of money between two" accounts. Berka at Abstract. A revenue budget is not an 
account, an expense budget is not an account, and a RIB rule does not transfer money 
between accounts. For at least these reasons, claim 4 should be allowed. 

Claim 14: 

Claim 14 is allowable, at least because Berka, and known credit/debit accounting, are 
inapplicable to the feature of "store the budget increase in an identified node of an 
expenditure budget data structure, and store the budget increase in an identified node of a 
revenue budget data structure such that the values in the expenditure budget data structure 
balance with the values in the revenue budget data structure." The credit/debit accounting of 
Berka "records actual transactions as transfers of money between two" accounts. Berka at 
Abstract. A revenue budget is not an account, an expense budget is not an account, and a 
RIB rule does not transfer money between accounts. For at least these reasons, claim 4 
should be allowed. 

Claim 17: 

Claim 4 is allowable, at least because Berka, and known credit/debit accounting, are 
inapplicable to the feature of "storing revenue budget items in a database, each item 
including a marker to indicate whether the revenue budget item was generated according to a 
RIB rule; [and] storing expenditure budget items in a database, so that the revenue budget 
items balance with the expenditure budget items." The credit/debit accounting of Berka 
"records actual transactions as transfers of money between two" accounts. Berka at Abstract. 
A revenue budget is not an account, an expense budget is not an account, and a RIB rule does 
not transfer money between accounts. For at least these reasons, claim 4 should be allowed. 

Claims 2, 3, 7 to 13, 15, 16, and 18 to 20: 
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Claims 2, 3, 7 to 13, 15, 16, and 18 to 20 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over Prentice, Berka, Kim, and in further view of U.S. Patent No. 
6,073,108 ("Peterson"). 

Claims 2, 3, 7 to 13, 15, 16, and 18 to 20, all depend from one of claims 1, 4, 6, 14, 
and 17. Since Peterson does not cure, nor was it asserted as curing, the deficiencies discussed 
above with respect to Prentice, Berka, and Kim, claims 2, 3, 7 to 13, 15, 16, and 18 to 20 
should be allowed for at least the same reasons as discussed above with regard to the 
respective independent claims. Therefore, Applicants respectfully request the rejections 
withdrawn, and the claims be allowed. 

CONCLUSION 

Applicants respectfully assert that all of the stated grounds of objection and rejection 
have been properly traversed, accommodated, or rendered moot. Applicants therefore 
respectfully request that the Examiner reconsider and withdraw all presently outstanding 
objections and rejections. Applicants believe that the present application is in condition for 
allowance. 

The Office is hereby authorized to charge any additional fees or credit any 
overpayments under 37 C.F.R. §1.16 or §1.17 to Kenyon & Kenyon Deposit Account No. 11- 
0600. If needed, Applicants request an extension of time to reply to the Advisory Action and 
the Office Action made final. 

The Examiner is invited to contact the undersigned at the telephone number below to 
discuss any matter concerning this application. 

Respectfully submitted, 

Date: August 18, 2009 /John B. Gillick, Jr./ 

John B. Gillick, Jr. 
Registration No. 63,027 

KENYON & KENYON LLP 
One Broadway 
New York, New York 10004 
(212) 425-7200 telephone 
(212) 425-5288 facsimile 
CUSTOMER NO. 53000 
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